Radio communication networks are widely deployed to provide various communication services such as telephony, video, data, messaging, broadcasts, and so on. Such communication networks support communications for multiple UEs by sharing the available network resources. One example of such a network is the Universal Mobile Telecommunications System (UMTS), a third generation (3G) mobile phone technology standardized by the 3rd Generation Partnership Project (3GPP). UMTS includes a definition for a Radio Access Network (RAN), referred to as UMTS Terrestrial Radio Access Network (UTRAN). The UMTS, which is the successor to Global System for Mobile Communications (GSM) technologies, supports various air interface standards, such as Wideband-Code Division Multiple Access (W-CDMA), Time Division-Code Division Multiple Access (TD-CDMA), and Time Division-Synchronous Code Division Multiple Access (TD-SCDMA). The UMTS also supports enhanced 3G data communications protocols, such as High Speed Packet Access (HSPA), which provides higher data transfer speeds and capacity to associated UMTS networks. As the demand for mobile broadband access continues to increase, research and development continue to advance the UMTS technologies not only to meet the growing demand for mobile broadband access, but to advance and enhance the user experience with mobile communications. For example, third-generation UMTS based on W-CDMA has been deployed in many places the world. To ensure that this system remains competitive in the future, 3GPP began a project to define the long-term evolution of UMTS cellular technology. The specifications related to this effort are formally known as Evolved UMTS Terrestrial Radio Access (E-UTRA) and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), but are more commonly referred to by the name Long Term Evolution (LTE). More detailed descriptions of radio communication networks and systems can be found in literature, such as in Technical Specifications published by, e.g., the 3GPP.
Currently, there is a discussion about HFN de-synchronization in 3GPP. For example, HFN de-synchronization and its impact to a Voice over LTE (VoLTE) call was discussed at the 3GPP TSG-RAN WG2 meeting #82 in Dresden, Germany, 18-22 Aug. 2014, see e.g. the 3GPP meeting document R2-143728. As is mentioned in R2-143728, HFN de-synchronization for uplink (UL) and downlink (DL) has been discussed multiple times. Recently, in RAN2 #86, companies where encouraged to “investigate further whether there are any de-sync issues in the field and whether it could be preferable to define UE behavior (e.g., earliest from Rel-12) for these cases.” Since then it has been confirmed that HFN de-synchronization is a reality, which may have an impact on VoLTE performance.
A potential problem with HFN de-synchronization for VoLTE is explained by the fact that operators use the Radio Link Control (RLC) Unacknowledged Mode (UM) Short (7-bit) PDCP sequence number (SN) option with an aim to minimize the packet overhead and thereby maximize coverage and capacity. If the UE is not scheduled in UL for a moment of time (e.g., a few seconds) due to e.g. a fading dip, then with short PDCP SN, there exists a risk that a PDCP entity of the UE discards too many already ciphered PDCP PDUs. For example, during a fading dip lasting a few seconds, it could be that too many ciphered PDCP PDUs in a row are either PDCP timer discarded by the UE because it is not scheduled or due to a long semi-persistent scheduling grant (e.g., transmitted but lost over the air). In other words, during a fading dip lasting a few seconds, it could be that too many ciphered PDCP PDUs in a row are discarded either due to the fact that lower layers do not find opportunities to transmit (e.g., discard by a PDCP timer expiry) or due to a loss of transmission over the air. Short PDCP SN wraps around after 128 PDUs which with 100% voice activity will cause HFN de-synchronization already after 2.56 seconds. Since SN uses 7 bits, it runs through 0, 1, 2, 3, . . . . 127 . . . and then “wraps around” just to run through 0, 1. 2, 3, . . . , again. This may cause duplicate SNs at the receiver, which can generally not be separated. Deciphering on the receiving side may then stall. In turn, this may be perceived as uncomfortable silence to the receiving end UE. The fault may pass unnoticed for the Key Performance Indicator (KPI) observer since VoLTE typically uses RLC UM for packet delivery.
One proposal to handle the HFN de-synchronization that is under discussion is to let the UE detect HFN de-synchronization on a RLC UM bearer and then have UE autonomously declare radio link failure whereupon the UE would fall back to the RRC_IDLE state, or RRC_IDLE mode (RRC is an abbreviation for Radio Resource Control). From the RRC_IDLE state, the UE would then initiate a re-establishment of the RRC connection. In other words, this proposal suggests that the network forces the UE to go to its RRC_IDLE state upon detection of a HFN de-synchronization incident.
The following is a reference that could provide additional background information to the reader. This reference may facilitate the understanding of one or more aspects of the technology described in this disclosure:                U.S. Pat. No. 8,180,299 B2, “Optimized AM RLC Re-Set Mechanism”, published on May 15, 2012. This document describes a mechanism for WCDMA whereby the RLC layer can be re-set. The RLC re-set procedure according to this document is triggered by a RLC delivery failure.        